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Abstract — Computational grids typically consist of nodes 
utilizing ordinary processors such as the Intel Pentium. 
Field Programmable Gate Arrays (FPGAs) are able to per- 
form certain compute-intensive tasks very well due to their 
inherent parallel architecture, often resulting in orders of 
magnitude speedups. This paper explores how FPGAs can 
be transparently exposed for remote use via grid services, by 
integrating the Proteus Software Platform with the Globus 
Toolkit 3.0. 
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I. Introduction 

Grid Computing describes an advanced distributed com- 
puting infrastructure, where resources are dynamically al- 
located according to the processing task requirements. 
These resources are usually compute nodes that may be lo- 
cated within an organization, or may be distributed across 
different organizations, in different geographical locations. 
To tie all these resources together, various grid computing 
'middleware' have been developed. Among the more popu- 
lar is the Globus Toolkit p^, which also offers an API that 
programmers can use to easily expose program functional- 
1 ity as a 'Grid Service'. 

Compute-intensive tasks have traditionally been run on 
grids / clusters of nodes having ordinary processors such 
as the Intel Pentium. More recently, there has been an 
increasing interest in the use of reconfigurable hardware 
processors called Field Programmable Gate Arrays (FP- 
GAs) to undertake these processing tasks. The inherent 
parallelism of processing done on FPGAs often allows for 
orders of magnitude speedups [2] compared to a normal 
processor. 

This paper explores how FPGAs can be transparently 
exposed for remote use via a grid service, by utilizing the 
Globus Toolkit and the Proteus Software Platform (PSP) 
0. Section |n] describes the architecture of the PSP and 
how it abstracts the underlying FPGA, Section IIIII dis- 
cusses the architecture of the Globus middleware, Section 
IIVI presents how the PSP was linked with Globus to allow 
for use of an FPGA via a Grid Service, and finally Section 
13 concludes the paper. 

II. The Proteus Software Platform 

The Proteus Software Platform (PSP) can be divided 
into four main component blocks: the PSP core, which 
holds the common set of interfaces and functionality, and 
three other components - the Software Modules, the Hard- 
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ware Abstraction Modules (HAMs), and the Proteus Ap- 
plication. This segmentation is illustrated in Figure ^ 



! Proteus Application 



Software Modules 



| Hardware Abstraction 
Modules 



Fig. 1 

Components of the PSP 



A Software Module consists of a set of Algorithm blocks 
which are linked up to form the desired processing chain. 
Each block defines a unit of operation that receives data at 
an input, processes it, and sends the results out through an 
output. This is commonly represented as shown in Figure 
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Fig. 2 

Algorithm block representation 



Since the PSP is intended to be run in environments 
where the available processor types are variable and deter- 
mined only during run-time, each Algorithm block may be 
associated with a number of implementations for different 
processor types. The resulting design takes on a 'shell / 
implementation' architecture as shown in Figure 

A Hardware Abstraction Module (HAM) defines a layer 
of abstraction to the underlying hardware, allowing the 
PSP to access and utilize various kinds of processor types 
and other PC resources via a common interface. This is 
done by modelling the desired properties of one or more 
physical hardware resources in one or more 'virtual proces- 
sor' entities, as shown in Figure The PSP dynamically 
matches the available algorithm implementations with the 
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Fig. 3 

The Algorithm 'shell / implementation' structure 



IV. Exposing use of the FPGA via a Grid Service 

A Globus HAM has been developed to represent a 'grid' 
type virtual processor, which encapsulates calls to exchange 
data via the Globus Toolkit. A 'ProteusGridService' Algo- 
rithm block compatible with this virtual processor type has 
been developed, and can be linked up to the rest of the Al- 
gorithm chain of the Software Module, as shown in Figure 
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available virtual processors, deploying them accordingly to 
build up the processing chain described by the Algorithm 
shells. 



Fig. 5 

Software Module with ProteusGridService Algorithm 
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Fig. 4 

Abstraction of physical hardware via 'virtual processors' 



The final component, the Proteus Application, defines 
the interface to the end-user. 

III. The Globus Toolkit 

The Globus Toolkit 3.0 exposes an API which program- 
mers can utilize to develop grid services as well as clients 
that access these services. In creating a grid service, the 
supported calls are specified in its associated WSDL file. 
The exchange of this file and the underlying connection es- 
tablishment protocol between the client and the grid service 
is encapsulated by the toolkit, and is therefore transparent 
to the programmer. 

The PSP and the Globus Toolkit are both built on the 
Java ,4 platform, hence simplifying the integration work 
needed for the PSP to sink / source data via a grid service. 
The next section describes in greater detail how this has 



Data to be sent / retrieved via the grid service is passed 
through the ProteusGridService' Algorithm, the Globus 
HAM's virtual processor, and from there through the 
Globus Toolkit. These layers of data exchange is illustrated 
in Figure El 
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Fig. 6 

Layers of data exchange 



The 'ProteusGridService' Algorithm block has a 'service- 
InstanceName' parameter that is initialized by the Software 
Module. This name will be used by the Globus virtual pro- 
cessor as that of the grid service name associated with this 
Software Module. Figure [7| shows a ProteusGridService 
Algorithm instantiated with the 'servicelnstanceName' pa- 
rameter initialized to " MyGridService" . 

When the PSP deploys this Software Module, the Pro- 
teusGridService Algorithm will be attached to the Globus 
virtual processor. Starting this virtual processor will in- 
voke the embedded Globus service container to expose a 
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Fig. 7 

ProteusGridService Algorithm 



grid service of name " MyGridService" . 
vice URL will correspondingly be: 



The full grid ser- 
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Once started, any remote client can subscribe to the grid 
service and exchange data with it, as shown in Figure |H1 
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Fig. 8 

Remote client access of grid service 



V. Conclusion 

This paper has presented how FPGAs can be exposed 
for remote use via grid services, by integrating the Proteus 
Software Platform with the Globus Toolkit 3.0. 



